NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/1129

Internet Message Format | 1996-08-06 | 5.1 KB

Path: engnews1.Eng.Sun.COM!taumet!clamage
From: Roman Lechtchinsky <[e-mail]>
Newsgroups: comp.std.c++
Subject: Re: Better template syntax?
Date: 17 Apr 1996 14:57:38 GMT
Organization: Technical University of Berlin
Approved: [e-mail] (comp.std.c++)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: taumet.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Nntp-Posting-Host: 130.149.17.236
X-Mailer: Mozilla 2.0 (Win95; I)
X-Lines: 95
Content-Length: 4200
Originator: clamage@taumet

Matt Austern wrote:
>
> In article <[e-mail]> Roman Lechtchinsky
> <[e-mail]> writes:
>
> > sorry for being curious but I'm only human... My question is: when declaring
> > templates, why isn't it required to declare what one expects of the
> > template's parameters? Let's create a template function:
> >
> > template<class T> bool equal( const T& t1, const T& t2 )
> > {
> >   return t1==t2;
> > }
> >
> > Now, personally I would prefer to write something like:
> >
> > template<class T { bool operator==( const T& t ) const; }> ...
>
> Specifying something like this correctly turns out to be extremely
> difficult: it's very hard to come up with syntax that neither
> overspecifies nor underspecifies the constraints.  In this particular
> case, for example: do you really care whether operator== takes a const
> T&, as opposed to a T?

Sure I do. If it takes a T the template needs access to the copy constructor.
This is something one tends to forget about - the compiler wouldn't let you
if you had to declare this fact.

> Does it matter that it returns bool, instead
> of something (like int) that is freely convertable to bool?

It depends on what this something is and whether you really want it to be
converted to bool or not ( in the case of operator== you almost certainly do;
maybe it's a bad example ). No problem if it is really int. If it is a class
which can be converted to bool or to int or even to a pointer then the
programmer should at least know which conversions might occur. Usually
templates are not documented that good.
As a matter of fact, my definition could accept an operator== with a
different return type. When calling it the return value would be converted to
bool prior to any other conversions which would give the programmer at least
some control.

> Does it
> matter whether this is T::operator==(T), or ::operator==(T,T), or any
> of a dozen other minor variations?

Note that this problem occurs only with operators. Again, the two operators
you mention have different semantics: the second one copies two objects
whereas the first one copies only one.

>
> More realistic cases are even harder to deal with.  Consider, for
> example, the for_each algorithm from STL:
> template <class InputIterator, class Function>
> Function for_each(InputIterator first, InputIterator last, Function f) {
>     while (first != last) f(*first++);
>     return f;
> }
>
> The constraints are as follows:
>   There must be either a built-in operator!=, or a global operator!=,
>     or a member function InputIterator::operator!=, such that applying
>     operator!= to two InputIterators is well-defined and yields something
>     that's convertable to bool.
>   Operators ++ and * are defined such that *InputIterator++ yields an
>     rvalue of some type.
>   An object of type Function has an operator() that takes an argument
>     of the type returned by *InputIterator++, or at least a type to
>     which the return value of *InputIterator++ can be converted.
>     The return value of operator() is unimportant.
>
> Notice what's tricky here: the important constraints are relationships
> between different types, some of which (like the return value of
> InputIterator++, and the return value of *InputIterator++) aren't
> named as template parameters.  This rapidly becomes a problem in
> formal specification.

Yes, sure. I could try to design a class  which messes the whole thing up
even though it provides everything the function needs. This rapidly becomes a
problem in application development :-) Essentially, templates are macros. One
can do a lot of things with macros. But should they be done? Maybe STL the
design of STL would be clearer if everything had to be declared...

>
> This issue is something that has been thought about, and there's some
> discussion of it in D&E.

Yes, there is ( I think so, at least; I don't remember who has my copy but
its not me ). However, in many threads about templates I've read something
like "now the semantics of templates are better understood". I'd like to hear
what people think about them in the light of this new understanding.

Bye

Roman


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:[e-mail]         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:[e-mail]                             ]